The present invention relates to Software Reliability Engineering (xe2x80x9cSRExe2x80x9d) methodologies; more particularly, the present invention relates to a method for developing operational profiles for software systems developed in multi-faceted environments.
An operational profile describes how the functionality of a software system is used. The development of an operational profile for a software system may allow one to more fully understand application usage and modes in addition to aiding the testing of the software system. From a testing standpoint, operational profiles help prioritization based on the most frequently occurring operations. Within SRE, testing with an operational profile and counting failures during such tests allows for the provision of accurate software reliability measures.
Traditionally, operational profiles are developed for a single-stand alone system. Today, however, software systems and components are often spread out across many sites, platforms, and machines. No clear cut way yet exists to adapt the traditional approach to the multi-faceted and n-tier environments-based systems being deployed currently. In addition, in the traditional approach, all operations are identified through interviews with the users, systems engineers and developers. Although operations must be identified in a very rigorous fashion, no definite beginning point for such identification exists in the traditional approach. Thus, in the traditional approach, there is no systematic method for developing an operational profile, and there are no consistent sources of information for this development. As a result, developing an operational profile using the traditional approach can be time consuming.
Use Cases and Use Case Modeling
Use case modeling is a methodology for developing the requirements specification for a software system. (As used herein, the term xe2x80x9csystemxe2x80x9d or xe2x80x9csoftware systemxe2x80x9d may refer to a group of individual software systems which together constitute a solution to a business need.) A requirements specification is a description of what the intended user of the software system needs or desires from the system.
A use case model is comprised of actors and use cases. Actors specify what is outside the system and describe roles that anything interacting with the system can play. Common examples of actors are users, other systems, network elements and the clock. Actors may be primary actors, which use the system directly, or secondary actors, which exist to support, supervise, or maintain the system. Secondary actors may support the primary actors in the primary actors"" use of the system.
A use case specifies the interaction between the actors and the system and specifies a part of the functionality performed by the system.
Outputs of use case modeling may include use case diagrams, descriptions of actors and their interfaces, and use case descriptions. An example of a use case diagram is shown in FIG. 4, which is described in detail below. Additional outputs of use case modeling may include interaction diagrams, data dictionaries and domain object models.
Two use cases may be related by an extension association. This association describes how one of the uses cases may be inserted into and extend the functionality of the other use case. The extension association can be shown on a use case diagram by labeling the relationship arrow between the extending use case and the extended use case with the stereotype (label) xe2x80x9cextendsxe2x80x9d. One can also state that the extending use case is of extends stereotype.
An example illustrating the extends relationship is shown in FIG. 1. In this figure, use case 101 is extended by use cases of extends stereotype 102, 103 and 104. In this example, use case 101 can exist independent of the inserted use cases 102, 103 and 104, and represents a functionality of the system meaningful in its own right.
Under the use case methodology, partial or complete commonality may be extracted or factored out of different use cases as a use case. Such a common use case is only meaningful to describe parts which are common to the use cases from which it was obtained. The relationship arrow between such a common use case and the use cases utilizing it can be labeled with the stereotype (label) xe2x80x9cusesxe2x80x9d. One can also state that such a common use case is of uses stereotype.
An example illustrating the uses stereotype is shown in FIG. 2. In this figure, use cases 201 (Display Office) and 202 (Generate Report) have in common the use case of uses stereotype 203 (Print). In this example, the use case of uses stereotype 203 is only meaningful to describe parts which are common to the use cases 201 and 202, from which it was obtained
A use case extended by a use case of extends stereotype can be said to be a driver use case for the use case of extends stereotype. Similarly, a use case from which a use case of uses stereotype was extracted or factored out can be said to be a driver use case for the use case of uses stereotype.
Further details on use case methodology can be found in Object-Oriented Software Engineering by Jacobson et al. (Addison Wesley, 1996).
Operations and Operational Profile Development
The present invention is concerned with the development of an operational profile. An operation is a complete task performed by a system. This concept is logical rather than machine-oriented in that a single operation can be executed over several machines and in noncontiguous time segments. An initiator invokes an operation or operations. An operation can be initiated by a user, another system, or the system""s own controller. An occurrence rate for an operation specifies how many times that operation is performed in a set amount of time. An occurrence probability for an operation is the probability of performance of that operation out of the complete set of operations considered.
An operations list is a list of operations together with initiators invoking the operations.
An operational profile is the set of operations that a software system can execute along with the occurrence rates and probabilities of the respective operations. An operational profile may allow one to more fully understand application usage and modes in addition to aiding the testing of the software system.
A software system may be used under a number of distinct circumstances, called operational modes, which may stimulate a number of distinct failures of the software system. Examples of operational modes include heavy load mode, end-of-month processing mode, steady-state mode, off-hours mode, and rarely occurring critical events mode. It may therefore be of interest to create an operational profile of the system for individual operational modes.
The drawbacks in known systems are overcome by the present invention, which identifies how to map use cases to an operational profile and how use cases are mapped to components. In embodiments of the present invention, the initiators of operations in the operational profile are identified from the actors of the use case model. A list of operations for the operational profile is created from the use cases of the use case model. Occurrence rates corresponding to the operations on the list of operations are obtained. Based on the occurrence rates of all the operations considered, the occurrence probabilities of the operations are calculated.